Re: [Kicad-developers] [PATCH] Crash Reporter
Hello, Am 16.04.19 um 23:25 schrieb Mark Roszko: > Just to throw it out there > > Did you consider at all at using something off the shelf such as > Breakpad which both Mozilla and Chrome use? > https://wiki.mozilla.org/Breakpad > https://github.com/google/breakpad this has also some downsides. The breakpad thing is nice for companies and projects that do provide ready to use binary packages no matter for Windows, Linux or MacOS platforms, just because they already know addresses from the used symbols and functions from the generated binaries. The backtraces are small and quite really anonymous and will mostly just hold signatures and hashes. But for all packages from the various Linux distributions you would need to know some internals from the build of the binaries and the packages later. You would also need a possibilities where the package creater could upload all these data plus a framework as a helper for doing this all. I've tried to get this all together for the Thunderbird package in Debian but due the complexity and the amount of work I haven't finished anything since almost two years. Not that the breakpad package is bad thing, no it's not! And I haven't looked into any implementation details from Tom. But for now I wouldn't hardly focus on this. And there wont be the one and only solution in the end I guess. But you need to start somewhere. -- Regards Carsten Schoenert ___ 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
Re: [Kicad-developers] Test failures
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 : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
[Kicad-developers] Test failures
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 common.holeyPolySet.CollideVertex( point, cornerHit, 0 ) has failed /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(179): error: in "SPSCollision/CollideVertex": check common.holeyPolySet.CollideVertex( point, cornerHit, 0 ) has failed /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(179): error: in "SPSCollision/CollideVertex": check common.holeyPolySet.CollideVertex( point, cornerHit, 0 ) has failed /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(179): error: in "SPSCollision/CollideVertex": check common.holeyPolySet.CollideVertex( point, cornerHit, 0 ) has failed /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(195): error: in "SPSCollision/CollideVertexWithClearance": check common.holeyPolySet.CollideVertex( point + VECTOR2I( 1, 1 ), cornerHit, 2 ) has failed /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(195): error: in "SPSCollision/CollideVertexWithClearance": check common.holeyPolySet.CollideVertex( point + VECTOR2I( 1, 1 ), cornerHit, 2 ) has failed /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(195): error: in "SPSCollision/CollideVertexWithClearance": check common.holeyPolySet.CollideVertex( point + VECTOR2I( 1, 1 ), cornerHit, 2 ) has failed /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp(195): error: in "SPSCollision/CollideVertexWithClearance": check common.holeyPolySet.CollideVertex( point + VECTOR2I( 1, 1 ), cornerHit, 2 ) has failed *** 8 failures are detected (2 failures are expected) in the test module "Common library module tests" These are reported for all three iterations of the common tests on Linux and Windows/VS. Simon signature.asc Description: OpenPGP digital signature ___ 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
Re: [Kicad-developers] [PATCH] Crash Reporter
On 16/04/2019 23:25, Mark Roszko wrote: > Just to throw it out there > > Did you consider at all at using something off the shelf such as > Breakpad which both Mozilla and Chrome use? > https://wiki.mozilla.org/Breakpad > https://github.com/google/breakpad Hi Mark, I took some inspiration from Mozilla (mainly the 'apologies' text ;-), but never had a serious look at Breakpad. I'm worried how many external dependencies it would bring (both on the software packaging and server side). Has anybody here used it? > > There's then some off the shelf software potentially for processing > Breakpad reports such as this service: > https://help.backtrace.io/pricing-data-protection-privacy-and-terms/pricing-and-tiers/backtrace-for-open-source > For the moment, the reporter uses a simple YAML-based format that is both human- and machine-readable. As such it's IMHO already quite useful, especially for tracking down Windows bugs (have you ever used GDB under Windows? :D) > > > Also do the data reports avoid identifying info such as usernames which > might fall under GDPR? Not to mention we'll need a privacy notice added > in somewhere anyway for collecting data. The user can always review the report text and (s)he's informed about this. No data is sent automatically. The report doesn't contain the username unless there's some DLLs/executables linked to KiCad existing in the home directory. No other personal data is collected (unless paths to system libraries/CPU register values/stack trace are considered personal data). Cheers, Tom ___ 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
Re: [Kicad-developers] [PATCH] Crash Reporter
On 16/04/2019 22:52, Seth Hillbrand wrote: > 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 us. It's loosely based on wxDebugReport, >> with a lot of new code (i.e. stack walker for windows or more meaningful >> report format...). >> >> This is particularly targeted at Windows/OSX users, since getting a >> useful stack trace on these systems is considerably more difficult (at >> least for non-programmers) than on (L)Unixes. >> >> I invite you to test it, in case recent KiCad nightlies have become too >> stable, you can always simulate a crash through 'Help->Simulate Kicad >> Crash'. >> >> Cheers, >> Tom > > > Hi Tom- > > I'm very happy to see these patches and am excited to try them out! > Unfortunately, like others, I won't have time to really poke at this > until after KiCon. But if others are comfortable with it, please don't > wait for me. Thanks Seth, no rush. See you in Chicago :) > > One addition that would be nice is making the destination URL and > enabling/disabling of the reporter advanced config settings instead of > defines. Good idea. I can add this. Tom ___ 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
Re: [Kicad-developers] [PATCH] Crash Reporter
Just to throw it out there Did you consider at all at using something off the shelf such as Breakpad which both Mozilla and Chrome use? https://wiki.mozilla.org/Breakpad https://github.com/google/breakpad There's then some off the shelf software potentially for processing Breakpad reports such as this service: https://help.backtrace.io/pricing-data-protection-privacy-and-terms/pricing-and-tiers/backtrace-for-open-source Also do the data reports avoid identifying info such as usernames which might fall under GDPR? Not to mention we'll need a privacy notice added in somewhere anyway for collecting data. On Sun, Apr 14, 2019 at 6:50 PM Tomasz Wlostowski wrote: > 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 us. It's loosely based on wxDebugReport, > with a lot of new code (i.e. stack walker for windows or more meaningful > report format...). > > This is particularly targeted at Windows/OSX users, since getting a > useful stack trace on these systems is considerably more difficult (at > least for non-programmers) than on (L)Unixes. > > I invite you to test it, in case recent KiCad nightlies have become too > stable, you can always simulate a crash through 'Help->Simulate Kicad > Crash'. > > Cheers, > Tom > > > > ___ > 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 > -- Mark ___ 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
Re: [Kicad-developers] [PATCH] Crash Reporter
Tom, On 4/16/19 4:52 PM, Seth Hillbrand wrote: > 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 us. It's loosely based on wxDebugReport, >> with a lot of new code (i.e. stack walker for windows or more meaningful >> report format...). >> >> This is particularly targeted at Windows/OSX users, since getting a >> useful stack trace on these systems is considerably more difficult (at >> least for non-programmers) than on (L)Unixes. >> >> I invite you to test it, in case recent KiCad nightlies have become too >> stable, you can always simulate a crash through 'Help->Simulate Kicad >> Crash'. >> >> Cheers, >> Tom > > > Hi Tom- > > I'm very happy to see these patches and am excited to try them out! > Unfortunately, like others, I won't have time to really poke at this > until after KiCon. But if others are comfortable with it, please don't > wait for me. > > One addition that would be nice is making the destination URL and > enabling/disabling of the reporter advanced config settings instead of > defines. > > Best- > Seth > I'm in the same boat as Seth. I will do my best to look at it as soon as possible but I've got a lot going on between now and KiCon so it may not happen until afterwards. Cheers, Wayne ___ 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
Re: [Kicad-developers] [PATCH] Crash Reporter
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 us. It's loosely based on wxDebugReport, with a lot of new code (i.e. stack walker for windows or more meaningful report format...). This is particularly targeted at Windows/OSX users, since getting a useful stack trace on these systems is considerably more difficult (at least for non-programmers) than on (L)Unixes. I invite you to test it, in case recent KiCad nightlies have become too stable, you can always simulate a crash through 'Help->Simulate Kicad Crash'. Cheers, Tom Hi Tom- I'm very happy to see these patches and am excited to try them out! Unfortunately, like others, I won't have time to really poke at this until after KiCon. But if others are comfortable with it, please don't wait for me. One addition that would be nice is making the destination URL and enabling/disabling of the reporter advanced config settings instead of defines. Best- Seth ___ 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
Re: [Kicad-developers] Uninitialised ZONE_CONTAINER members
Le 16/04/2019 à 19:36, John Beard a écrit : > Hi JP, > > I think the problem is that the members *within* ZONE_CONTAINER are > uninitialised, but they are accessed by the very act of trying to set > them from ZONE_SETTINGS::ExportSetting. If they had a spurious value > that was the same as the new value, the refill would not happen. Good catch! Well, this is a subtle "bug" that does not create actual issues. min thickness could be set to ZONE_THICKNESS_MIL (10mil), m_ThermalReliefCopperBridge could be set to ZONE_THERMAL_RELIEF_GAP_MIL (20mil), before calling aBoard->GetZoneSettings().ExportSetting( *this ); in class_zone.cpp See zones.h (These values are certainly a bit too large, nowadays) About refill, if we need a refill, it should be *clearly* called. > > The call stacks are as follows: > > ==12798== Conditional jump or move depends on uninitialised value(s) > ==12798==at 0x7CA4F4: ZONE_CONTAINER::SetMinThickness(int) > (class_zone.h:203) > ==12798==by 0xD752CE: > ZONE_SETTINGS::ExportSetting(ZONE_CONTAINER&, bool) const > (zone_settings.cpp:121) > ==12798==by 0xCF2AE0: ZONE_CONTAINER::ZONE_CONTAINER(BOARD*) > (class_zone.cpp:76) > ==12798==by 0xD57E0E: PCB_PARSER::parseZONE_CONTAINER() > (pcb_parser.cpp:3057) > ==12798==by 0xD4A86B: PCB_PARSER::parseBOARD_unchecked() > (pcb_parser.cpp:570) > ==12798==by 0xD4A3CD: PCB_PARSER::parseBOARD() (pcb_parser.cpp:486) > ==12798==by 0xD4A0E9: PCB_PARSER::Parse() (pcb_parser.cpp:465) > > ==12798== Conditional jump or move depends on uninitialised value(s) > ==12798==at 0xB299D2: > ZONE_CONTAINER::SetThermalReliefCopperBridge(int) (class_zone.h:178) > ==12798==by 0xD7537C: > ZONE_SETTINGS::ExportSetting(ZONE_CONTAINER&, bool) const > (zone_settings.cpp:129) > ==12798==by 0xCF2AE0: ZONE_CONTAINER::ZONE_CONTAINER(BOARD*) > (class_zone.cpp:76) > ==12798==by 0xD57E0E: PCB_PARSER::parseZONE_CONTAINER() > (pcb_parser.cpp:3057) > ==12798==by 0xD4A86B: PCB_PARSER::parseBOARD_unchecked() > (pcb_parser.cpp:570) > ==12798==by 0xD4A3CD: PCB_PARSER::parseBOARD() (pcb_parser.cpp:486) > ==12798==by 0xD4A0E9: PCB_PARSER::Parse() (pcb_parser.cpp:465) > > Cheers, > > John > > On Tue, Apr 16, 2019 at 5:38 PM jp charras wrote: >> >> Le 16/04/2019 à 17:59, John Beard a écrit : >>> Hi, >>> >>> The following members are not initialised in ZONE_CONTAINER's >>> constructor, but they are accessed in the Setter functions: >>> >>> * m_ThermalReliefCopperBridge >>> * m_ZoneMinThickness >>> >>> This was picked up with valgrind memcheck: >>> >>> valgrind --tool=memcheck qa/pcbnew_tools/qa_pcbnew_tools pcb_parser >>> /tmp/ciaa_acc.kicad_pcb >>> >>> What would be sensible defaults here? 0? >>> >>> Cheers, >>> >>> John >>> >> >> Strange: these parameters come from ZONE_SETTINGS class, and they are >> initialized in the ZONE_SETTINGS ctor ( min thickness 10mil, >> m_ThermalReliefCopperBridge 20mils ). >> >> >> -- >> Jean-Pierre CHARRAS >> >> ___ >> 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 > -- Jean-Pierre CHARRAS ___ 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
Re: [Kicad-developers] Uninitialised ZONE_CONTAINER members
Hi JP, I think the problem is that the members *within* ZONE_CONTAINER are uninitialised, but they are accessed by the very act of trying to set them from ZONE_SETTINGS::ExportSetting. If they had a spurious value that was the same as the new value, the refill would not happen. The call stacks are as follows: ==12798== Conditional jump or move depends on uninitialised value(s) ==12798==at 0x7CA4F4: ZONE_CONTAINER::SetMinThickness(int) (class_zone.h:203) ==12798==by 0xD752CE: ZONE_SETTINGS::ExportSetting(ZONE_CONTAINER&, bool) const (zone_settings.cpp:121) ==12798==by 0xCF2AE0: ZONE_CONTAINER::ZONE_CONTAINER(BOARD*) (class_zone.cpp:76) ==12798==by 0xD57E0E: PCB_PARSER::parseZONE_CONTAINER() (pcb_parser.cpp:3057) ==12798==by 0xD4A86B: PCB_PARSER::parseBOARD_unchecked() (pcb_parser.cpp:570) ==12798==by 0xD4A3CD: PCB_PARSER::parseBOARD() (pcb_parser.cpp:486) ==12798==by 0xD4A0E9: PCB_PARSER::Parse() (pcb_parser.cpp:465) ==12798== Conditional jump or move depends on uninitialised value(s) ==12798==at 0xB299D2: ZONE_CONTAINER::SetThermalReliefCopperBridge(int) (class_zone.h:178) ==12798==by 0xD7537C: ZONE_SETTINGS::ExportSetting(ZONE_CONTAINER&, bool) const (zone_settings.cpp:129) ==12798==by 0xCF2AE0: ZONE_CONTAINER::ZONE_CONTAINER(BOARD*) (class_zone.cpp:76) ==12798==by 0xD57E0E: PCB_PARSER::parseZONE_CONTAINER() (pcb_parser.cpp:3057) ==12798==by 0xD4A86B: PCB_PARSER::parseBOARD_unchecked() (pcb_parser.cpp:570) ==12798==by 0xD4A3CD: PCB_PARSER::parseBOARD() (pcb_parser.cpp:486) ==12798==by 0xD4A0E9: PCB_PARSER::Parse() (pcb_parser.cpp:465) Cheers, John On Tue, Apr 16, 2019 at 5:38 PM jp charras wrote: > > Le 16/04/2019 à 17:59, John Beard a écrit : > > Hi, > > > > The following members are not initialised in ZONE_CONTAINER's > > constructor, but they are accessed in the Setter functions: > > > > * m_ThermalReliefCopperBridge > > * m_ZoneMinThickness > > > > This was picked up with valgrind memcheck: > > > > valgrind --tool=memcheck qa/pcbnew_tools/qa_pcbnew_tools pcb_parser > > /tmp/ciaa_acc.kicad_pcb > > > > What would be sensible defaults here? 0? > > > > Cheers, > > > > John > > > > Strange: these parameters come from ZONE_SETTINGS class, and they are > initialized in the ZONE_SETTINGS ctor ( min thickness 10mil, > m_ThermalReliefCopperBridge 20mils ). > > > -- > Jean-Pierre CHARRAS > > ___ > 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 ___ 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
Re: [Kicad-developers] Uninitialised ZONE_CONTAINER members
Le 16/04/2019 à 17:59, John Beard a écrit : > Hi, > > The following members are not initialised in ZONE_CONTAINER's > constructor, but they are accessed in the Setter functions: > > * m_ThermalReliefCopperBridge > * m_ZoneMinThickness > > This was picked up with valgrind memcheck: > > valgrind --tool=memcheck qa/pcbnew_tools/qa_pcbnew_tools pcb_parser > /tmp/ciaa_acc.kicad_pcb > > What would be sensible defaults here? 0? > > Cheers, > > John > Strange: these parameters come from ZONE_SETTINGS class, and they are initialized in the ZONE_SETTINGS ctor ( min thickness 10mil, m_ThermalReliefCopperBridge 20mils ). -- Jean-Pierre CHARRAS ___ 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
[Kicad-developers] Uninitialised ZONE_CONTAINER members
Hi, The following members are not initialised in ZONE_CONTAINER's constructor, but they are accessed in the Setter functions: * m_ThermalReliefCopperBridge * m_ZoneMinThickness This was picked up with valgrind memcheck: valgrind --tool=memcheck qa/pcbnew_tools/qa_pcbnew_tools pcb_parser /tmp/ciaa_acc.kicad_pcb What would be sensible defaults here? 0? Cheers, John ___ 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
Re: [Kicad-developers] Zoom & Grid changes
Click-to-place tools moved to modern toolset. (Place component, no-connect, junction, wire-to-bus, bus-to-bus, label, hierarchical-label, global-label, text and image.) > On 14 Apr 2019, at 12:13, Jeff Young wrote: > > Net highlight tool now moved to modern toolset. > > >> On 13 Apr 2019, at 18:45, Jeff Young wrote: >> >> I just pushed changes to move Eeschema zoom control, Eeschema grid control >> and Pcbnew grid control to COMMON_TOOLS. >> >> Give a shout if you see anything odd…. >> >> Cheers, >> Jeff. > ___ 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
Re: [Kicad-developers] Monster files wanted
Hi, please have a look at this board (12 layers) https://github.com/ciaa/Hardware/blob/master/PCB/ACC/CIAA_ACC/ciaa_acc.kicad_pcb this is from 'Made with KiCAD' section. M On 04/16/2019 11:27 AM, John Beard wrote: Hi, Occasionally, there are references made to performance during processing of very large >8 layer PCBs (and the schematics thereof). However, I don't have any such PCBs to uses as a reference, and there are (reasonably, due to the size) none in the demos folder. I can make faked-up PCBs programmatically fairly easily (it's what was used in the DRC benchmarks a few weeks ago). But they are not necessarily representative of real workloads (or at least, cannot be demonstrated to be so). So, what are the biggest, meanest, most complex, processor-killing, resource-hogging, KiCad-crashing bad boys that people know of? Preferably open-source so they can be shared easily and used for benchmarking purposes. Cheers, John ___ 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 ___ 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
Re: [Kicad-developers] Monster files wanted
Hi John, Here are some big examples that I test my plugin on: https://github.com/OLIMEX/DIY-LAPTOP/tree/master/HARDWARE/A64-TERES/TERES-PCB1-A64-MAIN/Rev.C https://github.com/c4puter/motherboard https://github.com/rusefi/rusefi/tree/master/hardware/frankenso Regards, Andrew On Tue, Apr 16, 2019 at 2:27 AM John Beard wrote: > Hi, > > Occasionally, there are references made to performance during > processing of very large >8 layer PCBs (and the schematics thereof). > However, I don't have any such PCBs to uses as a reference, and there > are (reasonably, due to the size) none in the demos folder. > > I can make faked-up PCBs programmatically fairly easily (it's what was > used in the DRC benchmarks a few weeks ago). But they are not > necessarily representative of real workloads (or at least, cannot be > demonstrated to be so). > > So, what are the biggest, meanest, most complex, processor-killing, > resource-hogging, KiCad-crashing bad boys that people know of? > Preferably open-source so they can be shared easily and used for > benchmarking purposes. > > Cheers, > > John > > ___ > 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 > ___ 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
[Kicad-developers] Monster files wanted
Hi, Occasionally, there are references made to performance during processing of very large >8 layer PCBs (and the schematics thereof). However, I don't have any such PCBs to uses as a reference, and there are (reasonably, due to the size) none in the demos folder. I can make faked-up PCBs programmatically fairly easily (it's what was used in the DRC benchmarks a few weeks ago). But they are not necessarily representative of real workloads (or at least, cannot be demonstrated to be so). So, what are the biggest, meanest, most complex, processor-killing, resource-hogging, KiCad-crashing bad boys that people know of? Preferably open-source so they can be shared easily and used for benchmarking purposes. Cheers, John ___ 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
